大多数网络管理系统(NMS)为用户加载MIB提供了一种方法。加载MIB是NMS了解新MIB对象(如其名称、对象标识符(OID)和数据类型（例如，计数器）的一种方式。

MIB在加载时可能会被解析，或者稍后（例如，当NMS应用运行时）可能会进行解析。执行解析的软件是MIB编译器。

任何供应商的MIB编译器都应成功解析任何语法正确的MIB。遗憾的是，不同的MIB编译器可能会表现出不同的怪癖。

思科不断努力确保发布给客户的MIB在语法上正确。思科还避免了在常用NMS产品中证明存在问题的MIB构造。尽管做了这些努力，但无法满足该字段中所有MIB编译器的奇特要求。

本文档解决了一些常见问题，并提出了解决方法。如果您在供应商的MIB编译器中遇到上述任何问题(除RFC 14xx与RFC 19xx问题外)，则是由于该MIB编译器存在缺陷。您可能希望敦促您的供应商或供应商修复其编译器。

本文档的读者应熟悉MIB。

本文档不限于特定的软件和硬件版本。

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您使用的是真实网络，请确保您已经了解所有命令的潜在影响。

有关文件规则的更多信息请参见“ Cisco技术提示规则”。

加载顺序是加载MIB时最重要且最常见的问题。许多MIB使用在其他MIB中定义的定义。这些定义列在MIB顶部的IMPORTS子句中。

例如，如果MIB混乱从MIB混乱导入定义，则某些MIB编译器要求您在加载MIB混乱之前加载MIB混乱。如果错误的加载顺序，编译器将声明导入的MIB未定义。

这是许多其他MIB导入的MIB列表，以及加载它们的顺序。这可能会处理95%的加载顺序问题（大多数其他MIB可以按任何顺序加载）：

SNMPv2-SMI.my

SNMPv2-TC.my

SNMPv2-MIB.my

RFC1213-MIB.my

IF-MIB.my

CISCO-SMI.my

CISCO-PRODUCTS-MIB.my

CISCO-TC.my

注意：如果加载这些MIB的v1版本，则MIB文件名实际上将类似于IF-MIB-V1SMI.my(“ — V1SMI”)，它会添加到已从v2转换为v1的MIB的名称中。 此例外是RFC1213-MIB.my MIB，它仅作为v1版本存在（即，没有RFC1213-MIB-V1SMI.my）。

如果尝试加载另一个MIB，并且编译器抱怨未定义的项目，则确定此MIB从哪个MIB导入，并验证您先加载了所有其他MIB。

注意：对于每个MIB，在SNMP对象导航器>查看和下载MIB中，可以看到在MIB之前需要加载的MIB的确切列表(具有确切的编译顺序);选择查看MIB依赖项并下载MIB。

虽然Cisco MIB数据类型定义不会不匹配，但您可能会发现某些标准RFC MIB的情况是这样。例如：

MIB混乱定义：SomeDatatype ::= INTEGER(0.100)

MIB组件定义：SomeDatatype ::= INTEGER(1..50)

此示例被视为轻微错误，MIB成功加载并显示警告消息。

下一个示例被视为非简单错误（即使两个定义本质上是等效的），并且MIB未成功解析。

MIB混乱定义：SomeDatatype ::= DisplayString

MIB组件定义：SomeDatatype ::=八位组字符串(SIZE(0.255))

如果MIB编译器将这些错误视为错误，或者如果您希望消除警告消息，请编辑定义此相同数据类型的MIB之一，以便定义匹配。

如果加载这些MIB，您可能会遇到OID重新定义（尽管可能存在发生此错误的其他实例）：

OLD-CISCO-CPU-MIB.my

OLD-CISCO-ENV-MIB.my

OLD-CISCO-MEMORY-MIB.my

OLD-CISCO-SYSTEM-MIB.my

例如：

OLD-CISCO-CPU-MIB.my定义：lcpu对象标识符：:= { local 1 }

OLD-CISCO-ENV-MIB.my定义：lenv对象标识符：:= { local 1 }

加载这两个MIB时，MIB编译器可能会抱怨lcpu OBJECT IDENTIFIER正在用新名称lenv重定义。OLD-CISCO-MEMORY-MIB.my和OLD-CISCO-SYSTEM-MIB.my同样为{ local 1 }指定新名称。

这被视为轻微错误，MIB成功加载并显示警告消息。

如果MIB未成功加载，或者您希望消除警告消息，请编辑其中一个MIB，使所有MIB使用相同的名称。

许多MIB编译器具有某些数据类型（如DisplayString）的内置知识。其中一些编译器在MIB中看到这些数据类型的定义时会抱怨。例如，DisplayString在SNMPv2-TC中定义。

解决方法是删除或注释掉MIB文件中的违规定义。

这是一个语法上有效的示例，它表示MyDatatype类型的值将是0、5或20个二进制八位数的长度：

某些MIB编译器不接受此语法。通常，一个充分的解决方法是选择其中一个尺寸，然后删除其它尺寸。你应该保持最大尺寸。例如，上一个示例将更改为：

某些OID被视为奇数，因为它们不引用SMI中的节点(与大多数OBJECT IDENTIFIER一样)。 但是，它们在语法上是有效的。常见示例是空对象标识符，例如{ 0 0 }。某些MIB编译器不关心与SMI中的节点不对应的OBJECT IDENTIFIER。以下是MIB语法示例，这些语法可能导致以下编译器出现问题：

解决方法是删除或注释掉MIB文件中的这些类型的引用。

在SNMPv1 MIB中，陷阱是使用TRAP-TYPE宏定义的。在SNMPv2 MIB中，陷阱是使用NOTIFICATION-TYPE宏定义的。

某些MIB编译器不喜欢它们解析的MIB文件中的这些定义（它们不支持这些宏）。

如果是这种情况，您可以删除陷阱定义或注释掉定义(例如，在行首放置MIB注释分隔符)。

RFC 1442至1452定义基于参与方的SNMPv2。这些RFC被更新的标准草案RFC 1902至1908淘汰。

在MIB语法方面，这两个版本的SNMPv2之间几乎没有区别；不过，也有一些。Cisco MIB当前基于RFC 19xx规则。

注意：几年前，当Cisco MIB基于RFC 14xx时，一些基于RFC 19xx的编译器会抱怨CISCO-TC.my和PNNI-MIB.my MIB中的Unsigned32 :::= TEXTELIC-CONVENTION行。这是因为Unsigned32是RFC 19xx中的预定义数据类型。因此，思科过去有这些MIB（CISCO-TC-NO-U32.my和PNNI-MIB-NO-U32.my）的替代版本，没有Unsigned32的定义，可加载到已知此数据类型的编译器中。这不再适用。

将Cisco MIB、陷阱和图标加载到第三方NMS的最佳最有效方法是使用CiscoWorks集成实用程序（集成实用程序），该实用程序可作为CiscoWorks公共服务(或从http://www.cisco.com/cgi-bin/tablebuild.pl/cw2000-utility独立)的一部分提供，并具有来自http://www.cisco.com/tacpage/sw-center/cw2000/cmc3rd.shtml的相应集成实用程序适配器和最新的网络管理集成数据捆绑包(NMIDB)。 有关详细信息，请查看集成实用程序文档。

或者，您可以查阅有关MIB加载和编译的第三方NMS文档。本文档包括有关HP OpenView和IBM NetView的说明；但您仍应查阅HP或IBM文档，因为产品可能会发生变化。

按照以下步骤加载所需的Cisco MIB:

将文件复制到网络管理站的目录/usr/OV/snmp_mibs中。

这是HP OpenView和IBM NetView查找MIB文档的默认目录。如果将它们放在其他位置，请在loadmib图形界面中指定显式路径名。

设置权限，以便您对MIB具有读取访问权限。

从GUI菜单中，选择“选项”>“加载/卸载MIB”。

按照平台文档中的说明编译或加载Cisco MIB。

发出/opt/OV/bin/xnmloadmib -load filename命令，以加载MIB文件。